Add a flag to populate source revision as commonAnnotation #1509
Conversation
|
This will cause drift on every apply, even if no objects have been modified in source, so this can't go in. |
Signed-off-by: Adrian Fernandez De La Torre <[email protected]>
adri1197
force-pushed
the
otel-source
branch
from
108d836 to
aaf81e9
Compare
I was thinking about comparing the If your concern goes more on, if the revision annotation is going to be added regardless of being a modified file/resource controlled by the Kustomization, some kind of dry-run could be used to detect any drift between. However, I don't see this as a good approach resource as well as time wise. |
| cmeta.Annotations = make(map[string]string) | ||
| } | ||
| for k, v := range revisionAnnotations { | ||
| cmeta.Annotations[k] = v |
There was a problem hiding this comment.
Why are we annotating all resources? A Kubernetes deployment will never send an event to NC. This will cause drift for potentially thousands of non-Flux resources, which negates one of the core Flux design principles, we never alter the cluster state, unless a change is made in Git; in this case, no change was made in Git, you just blindly mutate all objects.
There was a problem hiding this comment.
Oh sorry.. this was just a raw implementation. Of course, there is no need to add the annotation in non-FluxCD resources. In any case and as far as I understood, it wouldn't fly due to mutating the objects at applying, been a drift between the source and what's applied and therefore, as you said, altering the cluster state.
I thought that to properly populate the revision over the resources controlled by a Kustomization, it should get spread over from that, because it does have full-control about what's going get applied in the cluster in the end.
Do you have any suggestion about how to tackle this? I think it's a valid use case, especially when you rely on having most of your FluxCD resources in a source/several sources and reconciling from them.
2 participants
Part of: fluxcd/flux2#5510